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ABSTRACT 


The most important software requirement for any robot development is 
the COGN itive Operating S YS tem (COGNOSYS). This report describes the 
Stanford University Artificial Intelligence Laboratory* s Hand/Eye software 
system from the point of view of developing a cognitive operating system for 
JPL's Robot. In this, the Phase I of the JPL Robot COGNOSYS task the 
installation of a SAIL compiler and a FAIL assembler on Caltech's PDP-10 
have been accomplished and guidelines have been prepared for the implemen- 
tation of a Stanford University type Hand/Eye software system on JPL- 
Caltech's computing facility. The alternatives offered by using RAND-USC's 
PDP-10 Tenex operating system are also considered. 
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I. INTRODUCTION 


The most important software requirement for any robot development 
is what may be termed the COGnitive Operating SYStem (COGNOSYS). The 
COGNOSYS is to be distinguished from the operating system of the host com- 
puter on which the cognitive operating system is implemented and resides. 
The JP L robot's sensory-motor functions consist of those corresponding to 
stereo-TV cameras, range finder, arm(s), and vehicle drive mechanisms. 
None of the robots either in existence or under current development, to the 
author's knowledge, have this mix of effectors. The Stanford Research 
Institute's SHAKE Y has no arm. The Stanford University Artificial Intelli- 
gence (A. I. ) Laboratory's Hand/Eye (HE) system has no mobility. The 
approach taken by these two centers of robotics in the development of cogni- 
tive operating systems are distinctively different from each other. Stanford 
Research Institute's SHAKEY has a cognitive operating system which is 
designed around a theorem-prover (the QA 3- STRIPS- PLANEX approach) 
whereas the Stanford University A. I. Laboratory utilizes heuristic strategy 
program to control the serial/parallel execution of a directory of special- 
purpose subroutines (jobs, modules), where each subroutine, for example, 
may be a directive for a specific operation on the robot's subsystem. 

This report formulates a methodology for developing a cognitive 
operating system and describes the Stanford University A. I. Laboratory's 
HE system from the point of view of developing cognitive operating system 
for Jet Propulsion Laboratory's robot breadboard. In the Phase I of the 
COGNOSYS task the installation of a SAIL compiler and a FAIL assembler on 
Caltech's PDP-10 have been accomplished and guidelines set forth for the 
implementation of a Stanford- type HE software system on JPL- Caltech' s 
computing facility. The alternatives offered by using RAND-USC's PDP-10 
Tenex operating system is also considered. 
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II. METHODOLOGY 


The methodology for the development of JPL robot's cognitive 
operating system (COGNOSYS) from what was evident at the inception of this 
project to what has evolved to date may be expressed thus: There was no 

intention to be restricted to in-house capabilities alone but rather to acquire 
as much benefit as possible by interacting with nationally known artificial 
intelligence centers. These benefits would constitute in the awareness of the 
latest developments relating to cognitive operating systems and in broaden- 
ing the knowledge base of JPL researchers. 


Specifically, these interactions would result in the importation of 
artificial intelligence specific programming language compilers, assemblers, 
and utility routines. They would also result in the understanding of 
rnr.MncvQo nr under development at other centers, in the importa- 

tion of these cognitive operating systems followed by in-house experimenta- 
tion with them. This understanding and experimentation (either at JPL or at 
site of origination) coupled with the JPL specific robot requirements would 
lead to the modification and extension of these (imported) packages to fit the 
JPL robot's needs. 


Should it be indicated, in the course of the study, that the effort 
required to modify and extend these packages is not commensurate with the 
effort required to develop these software packages from functional descrip- 
tions and flow charts, then requisite steps would be taken to seek an inter- 
mediary balanced approach. Such decisions may come about due to 
incompatibilities of host machines, time- sharing s ystems , and availability 
of compilers. Should the host machine compatibilities be of a marginal 
nature then intermediary steps, between the extremes of: (1) direct import 

and translation, and (2) total in-house specified development, are indicated. 
That is to say, the task will comprise some of those imported packages that 
are directly utilizable, those that will be utilizable after some modification, 
other packages that may not thus be utilizable but must be developed and 
written from basic specifications, and packages which do not exist anywhere, 
are JPL specific, and hence must be developed here (e. g. , those relating to 
a robot functioning in a Mars environment). 
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III. OVERVIEW OF HAND/EYE SYSTEM 


The HE system consists of a group of jobs which are all constrained to 
some particular conventions (Fig. 1). These conventions enable communica- 
tion of data and control information among the jobs. For the purpose of 
clarity, these separate jobs may also be referred to as modules. Each 
module represents a logical physical section of the HE system. 

All of these modules are run as pseudo-teletype (PTY) jobs under the 
PDP-10 timesharing system. The user is provided with a teletype (TTY) 
controller which is responsible for communicating with the various modules 
in the system. The TTY controller allows commands to be passed to these 
modules and allows output from the modules to be shown to the user. 

The PTY mechanism is used for controlling the modules to accommo- 
date the timesharing system (e. g. , logging in, executing system commands, 
etc. ). Since this is not a practical way of communicating large quantities of 
data, another mechanism has been provided for making data available to all 
modules and for communicating data between modules. This mechanism 
makes use of the second segment on the PDP-10. All modules share a 
common second segment which contains the SAIL routines and global data 
storage space. 

Since the second segment is common to all modules, it may also be 
used for passing information from one module to another. This information 
is passed in the form of "messages" which resemble SAIL procedure calls. 
Messages promote a means for passing data and for requesting executing of 
so-called "message procedures" in the various modules. 

A. Hardware Overview 

The HE system's visual input is accomplished by using a commercial 
TV camera. The camera has a four-lens turret, a four-position color wheel 
in front of the vidicon, a pan-tilt head, focus, and target voltage all under 
program control. The arm is powered by small electric motors mounted on 
it. Each of the joints has a potentiometer mounted on it to provide position 
feedback. The hand is a two-finger parallel grip device. The TV and arm 
are connected through analog-to- digital converters to a Digital Equipment 
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PDP-6 and a PDP-10 computer linked together and sharing 128K of core 
(which has recently been augmented to the full 256K of core). 

All analog -to -digital and digital-to-analog convertors interface with 
the PDP-6. All I/O devices between the HE and computing system are 
attached to the PDP-6. The PDP-6, in general, is used for real-time 
applications such as servoing the arms, changing lenses, changing color 
filters, pan, tilt, etc. 


B. Storage Requirements 


The approximate estimate on storage requirements for the assembler, 
compiler, jobs, global segment, and HE monitor are the following: 


FAIL assembler 
SAIL compiler 
HE defined jobs 
Global models and run 
time routines 
Other storage allocations 
HE monitor 


19 to 42K 
23 to 50K 
40K and more 


27K 
3 to 4K 
6K 


C. Software Overview 

The HE system runs under Stanford's PDP-10 timesharing system, 
which has been modified to enable the HE system to function in a timesharing 
environment. The HE system is partitioned into many intercommunicating 
modules. Each module runs as a separate job under the PDP-10 timesharing 
system. This division alleviates job sizes limitations. It also allows the 
timesharing scheduler to overlap computation-limited operations like arm 
servoing. There are, however, two inefficiencies associated with the use of 
multiple jobs to avoid core overlays; one in the overhead of trapping and 
routing I/O from all jobs through a single terminal. The second is the 
difficulty of bringing task-dependent strategies to bear on scheduling 
decisions . 

Most of the HE system is written in SAIL (except for the run-time 
routines which are mostly in FAIL). SAIL is an ALGOL- like language which 
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contains the LEAP associative processing language. To enable various 
sections to run asynchronously, and to fit it into core, the system runs as 
eight separate programs. The PDP-10 has two relocation registers, allow- 
ing a program to be in two disjoint segments in core. One of these segments, 
known as the upper segment, is common to all the programs and contains 
reentrant subroutines common to all programs. In addition, it contains data 
which provides a complete global model of the world as it is known to the 
system at any given time. This model is generated by the lower segment 
programs and can be interrogated by them. It is predominantly in the form 
of LEAP associations. 

The HE monitor (which resides in the lower segment) is the only pro- 
gram that communicates directly with the operator. It activates PTYs and 
logs in jobs through them. All characters sent to a PTY by the monitor go 
to the teletype input buffer of the job attached to the PTY, and any teletype 
output from a job is available to the monitor. The monitor also contains 
facilities for directing teletype input to the proper job, outputting teletype 
output from the jobs to the operator with the job identified, tracing the 
teletype I/O and message procedure calls for debugging, and setting up and 
controlling the other jobs. Jobs may also activate a message procedure in 
the monitor to send commands to it (Figs. 2 and 3). 

D. Data Representation: LEAP Triplet Association 

An important form of storage of item instances is the association, 
or triple. Ordered triples of item instances may be written into or retrieved 
from a special store, the associative store. The method of storage of these 
triples is designed to facilitate fast and flexible retrieval. A triple is 
represented by: 


Attribute (x) Object = Value 

where A, O, and V are items or item vars and are mnemonics for attribute, 
object, and value, respectively. 
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Examples : 

(1) BLOB (x) TABLE [i, j] = blobs known to be in area where 
TABLE is an item var array (whose indices are X/4, Y/4 where 
X and Y are in inches and are table coordinates) and where 
BLOB is the set of connected edges traced by the edge follower 
(it may be one or more objects). 

(2) COLOR (x) CUBE = RED 

which reads "color of cube is red. " 

(3) COLOR (x) ? = RED 

which defines the set of all red objects. 

E. S trategy or Control Program 

The heart of the HE system is the control program. The control 
program sequences the various tasks, attempts error recovery, generates 
displays, and has provision for running parts of the system by themselves 
for debugging. The strategy or control program that exists at Stanford 
University is a program that enables the HE system to autonomously solve 
the "Instant Insanity" puzzle (Fig. 4). The puzzle consists of four cubes, 
each with faces variously selected from four colors: white, blue, red, and 
green. To solve the puzzle, the blocks must be stacked so that each of the 
four sides of the resulting tower reveals only one face of each color. 
Determining the orientation of the cubes in the tower is normally quite 
difficult for humans. For the computer this is relatively easy. Most of its 
time and effort is spent in locating and identifying objects, determining the 
colors of the faces, and, having found the final orientation, deciding what 
arm motions are required to physically produce the tower. 
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IV. PSEUDO-TELETYPES 


A PTY is an artificial construct within the system to allow users to 
have and control more than one job at a time. If you do output PTY, it is 
as if you were sitting at a teletype typing those characters that you outputted. 
The PTY reads your characters just as a regular teletype does. If you send 
the character "Login" followed by a carriage return, line feed to a PTY, it 
will log in a job just as if you had typed that to a teletype. The PTY will then 
type back the duplexing of what you typed as well as the usual message the 
system puts out when someone logs in. 

The job which initiates a PTY owns it uniquely, and no other job may 
appropriate that PTY. Using the PTY unused operations (UUOs) one can 
accomplish from a program anything one can from a command by sending the 
command to the monitor and performing a PTY UUO with the line number set 
to zero. That is to say, if you perform a PTY UUO with the line number in 
ADR set to zero, it is as if the user had typed those characters you outputted. 
Thus, a job can stop itself by sending control-C to line number zero. 

A. Hand/Eye PTY Mechanism Procedures 

The program designed to handle PTYs for the HE system (Fig. 5) 
consists of the following procedures: 


DP YC LEAR: 

Turn off display frame, put out by job I (3 displays 
only for now). 

DOIT: 

Procedure to set and reset flags (used in command 
decoder). 

CORE: 

Procedure to determine job size. 

STRTST : 

Procedure to indicate when string space nearly empty. 

TIMOUT: 

Procedure to output millisecond time as MIN; SEC; 
FRACTION. 

FORM: 

Procedure to format strings. 
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TRACE: 


MON-COM : 

SCANLOOP: 


TYPEX: 

Procedures t 

HALT : 

SEND : 

SNARF : 

SNARFMQN: 

WAITI: 

COMSCAN: 


COMMAND: 


Message procedure tracing functions: 

GETVAL 

GETREAL 

GETSTRING 

GETBITS 

GETARGS 

Procedure to send commands to the monitor from 
the jobs. 

Procedure to scan the TTY and all the logged in PTYs 
to see if there is input waiting, and to take appropriate 
action. 

Procedure which types all strings to TTY; it handles 
suppress and trace processing. 

help control the PTYs: 

Halts the job ID number in COMJOB. 

Sends strings at the PTY for a job ID number. 

Waits until a certain character is seen from that PTY. 
Arranges for that PTY to be in monitor mode. 

Waits for a character from a given PTY and returns it. 
Command scanner. It is called if the scanner loop 
detected that there was input from the TTY. It checks 
to see if there is a new job destination and, if so, 
stores the logical name. If there is a command, the 
logical name of the destination and the job ID number 
are stored. If there is no command, the line is typed 
at the appropriate PTY job. 

Command decoder. It is called by COMSCAN if a 
command is detected. This parses the command, looks 
it up in the command table, and may then parse argu- 
ments to the command. The command name and parsed 
arguments are stored in ARGS array. Then dispatch 
is made on the command number for the command. 

This dispatch is in the form of one big case statement. 
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V. GLOBAL MODEL 


The HE system is composed of several distinct jobs or modules all 
running independently for the purposes of the time-sharing system. How- 
ever, these modules will actually be about one common task, are able to 
communicate with each other. This communication is implemented in two 
ways: a global data space located in a second segment shared by all the 

hand/ eye modules, and a facility for passing messages between the modules. 

All HE modules have access to all the data stored in the global area. 
The declarations for global data are all included in a declaration tape that 
precedes the SAIL compilation of each module. This insures that space is 
allocated such that each separate module knows the same name for a given 
price of global data (thus avoiding the FORTRAN COMMON problem). 

The contents of the global tape are arrived at by agreement and precede 
each SAIL compilation to be loaded as part of the HE system. 

A. Parallel Processing Using S pacewar Mode 

Spacewar mode is essentially a parallel process. A job designated in 
Spacewar mode and started up runs independently from the main job. 

One of the important points in a timesharing system is that users' 
requests for time are scheduled. As a user uses more and more time, his 
priority goes down and he gets larger and larger time slices. However, 
completely invisible to the user, his program gets shut off periodically to 
allow other users to run. This means that no user gets continuous service, 
but they all get interrupted and shut off periodically. There exists a need 
for perfectly regular service; e. g. , if the SU's hydraulic arm were in oper- 
ation, a shutdown of any length would cause the arm to wilt. It is for this 
reason that a mode of operation exists that guarantees perfect (almost) 
regular service — namely, the Spacewar mode. 

When a Spacewar job is initiated, the initiator specifies the time 
intervals between startups. The Spacewar job will be started from the 
beginning after that amount of time. While the Spacewar module is active, 
this job is locked into core and may not be swapped out. 
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B. 


dures and Forward Message Procedures 


Message Proce 

Message procedures (MPs) provide a mechanism for communicating 
among the various modules of the HE system. Each of these modules 
communicate with the common second segment, hence the intra-module 
communication paths are established, in that segment. 

Mes sages are passed back and forth in the second segment. The 
history of a message may be some subset of the following sequence: 

(1) Message is composed. 

(2) Message is put in sequence. 

(3) Message is "sent." 

(4) Wait for completion of the message. 

(5) Activate the message (call the procedure). 

(6) Acknowledge the processing of the message. 

(7) Kill the message. 

The capability is needed to send messages that have SAIL-like data 
associated with them. It is not desired to convert all message data to some 
symbolic form and (say) write a disk file with that text, but instead to pass 
data of all types (sets, items, arrays, integers, reals, etc.) in a reasonably 
efficient manner. At the same time it is desired that programs do not have 
to explicitly type-check message data or explicitly have to do "get this datum" 
operations - 

A mechanism which meets the above requirements is already in SAIL, 
namely, actual parameter passing to procedures. A message, then, will 
consist of a name of a procedure and a parameter list to pass to that proce- 
dure for evaluation, together with some bookkeeping information. The 
user is allowed to specify a symbolic source and a symbolic destination of the 
message. These names specify the module to be activated (i. e. , the recipi- 
ent of the message), and the source module. 

Thus a mechanism is implemented for a user in one module to emit 
calls to procedures actually located in another module. The matching and 
passing of formal parameters is handled in much the same way as for 
ordinary procedures. Of course, the calling module must have declared the 
names and parameter lists of the procedures it is calling. These 
declarations will be in the HE definition tape and will look like ordinary 
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procedure declarations, except that the words FORWARD MESSAGE 
PROCEDURE appear. 

A mechanism must be provided in the module in which this procedure 
is actually located in order to allow this procedure to be evaluated for each 
message passed to it. It could be arranged that whenever a message 
specifying the evaluation of some procedure was passed to a module, that 
module is interrupted and the message request honored. But this is unthink- 
able, for many reasons. First, the module should control the priorities 
with which messages are evaluated. Second, it would be objectionable to 
suspend the module in the midst of a computation which has left an incon- 
sistent view of the world in its data structures. 

To rectify this, a module must specifically receive messages, and 
must request the evaluation of the specified procedure. Briefly, a module 
may look around in the list of messages in order to locate one destined for 
itself. It may then request that the message be activated, i. e. , evaluate the 
procedure which is located in the module reading the message and which has 
the same name as the "procedure name" specified in the message. This 
evaluation is performed with the arguments as specified in the message. 
Normally, when the procedure exists, the message is acknowledged (i. e. , 
the calling module may now determine that the message has completed). 

C. Tracing 

There is a facility for tracing messages passed from one job to another 
(Fig. 6). This facility is actually handled by the same program which 
handles the TTY-PTY operations. A trace consists of a type-out at the 
controlling TTY of the form: "time MESSAGE TRACE: source destination 

message-procedure-name args" where time is in milliseconds since mid- 
night. Args is a list of argument data for the message procedure. The 
mechanics of tracing are that there is a global variable in the second seg- 
ment called TRACING. If it is set non-zero, message tracing is enabled. 
Every time a message is sent by the message handler, a trace message is 
first sent to the tracing job. When the tracing message is acknowledged, the 
original message is finally sent to its prescribed destination. An example 
of a trace that was conducted on the HE system is included in Appendix C 
of this report. 
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VI. UUOs, CALLs, AND CALLIs 


The unused op codes from 040 to 077 (in octal) are not used by any 
instruction and are made use of to communicate with the monitor. These 
are the UUO codes. An UUO is an instruction which is executed by the 
system instead of by the computer. These UUOs are used for such functions 
as to initialize devices, to set up buffer rings, to manipulate files, to make 
data transfers, to terminate i/O, and to deal with specific I/O devices such 
as teletypes, magnetic tapes, display units, and DECtapes. Op-codes 040 
through 077 and 000 trap to absolute location 40, with the central processor 
in executive mode, and these programmed operators are interpreted by the 
monitor to perform I/O operations and the functions in the foregoing 
des cription. 

The previous paragraph described functions of the monitor UUOs. 

There are also User UUOs, which are op-codes 001 through 037, and which 
allow the user program complete freedom in the use of these programmed 
operators while not affecting the mode of the central processor. 

Op-codes 040 through 077 limit the monitor to 40g operations. The 
UU 0 040, which is the CALL operation, extends this set by specifying the 
name of the operation by the contents of the location specified by the effective 
address. This capability provides for indefinite extendability of the monitor 
operations. 

However, the CALL mechanism introduces an overhead cost of a table 
lookup to the monitor. Thus there is a programmed operator extension of 
the UU0 047 referred to as CALLI. The CALLI operation eliminates the 
table lookup of the CALL operation by having the programmer or the assem- 
bler to perform the lookup and specify the index to the operation in the 
effective address of the CALLI AC, N instruction, where N is an index to the 
operation. 

The PDP-10 operating system of the Stanford University A. I. Labora- 
tory recognizes CALLIs up to N = 41 as standard, i. e. , these were the 
standard CALLIs that came with the operating system supplied to them by 
DEC. These CALLIs (also loosely referred to as UUOs) have been extended 
by Stanford; i. e. , new ones have been defined. In fact, 46 new CALLIs have 
been defined, bringing the total to 87. 
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However, in the meantime DEC has not been idle, and in their new 
versions of their PDP-10 operating system (50 series) 107 CALLIs are 
defined, i. e. , sixty-six new CALLIs have been defined since they supplied 
their operating system to Stanford, No doubt the impetus to do this may 
have well come from the ideas developed by Stanford. 

Nevertheless, in performing the task of developing an HE-type monitor 
at JPL by "fitting" the Stanford HE monitor to Caltech's PDP-10, the avail- 
ability of these new CALLIs is significant. These new CALLIs can now be 
used to replace many of the Stanford specific ones; e. g. , DEC'S CALLI 
AC, 60 has the function of locking jobs in core so that they may not be swapped 
out, whereas Stanford has a number of SPACEWAR UUOs (see Subsection Y. A) 
that perform functions toward similar objectives. 

In summary, although DEC now provides CALLIs that are similar 
to those developed at Stanford thus making "translation" to Caltech's PDP-10 
easier, it should be noted that they are only functionally similar and may not 
necessarily enable simple direct replacement. This issue will be investigated, 
in Phase II of this task. 

A list of Stanford's standard DEC CALLIs as well as their own defined 
CALLIs is attached in this report (Appendix B). 

A. Summary of Ph ase I 

The two major trends in cognitive operating system design were 
referred to in the introduction, namely Stanford Research Institute's theorem- 
prover-based QA3-STRIPS- PLANEX approach and the Stanford University 
Artificial Intelligence Laboratory's approach, which is to use a heuristic 
strategy controller of a directory of jobs. 

Initially some effort was made to survey theorem-proving techniques 
and theorem-prover-based question-answering systems. Along these lines 
the QA 3. 5 package developed by Cordell Green and associates at Stanford 
Research Institute (SRI) was obtained and installed on Caltech's PDP-10. 

After very little experimentation it was evident that theorem-prover-based 
deductive systems are indeed very slow. Their strength lies in powerful 
deductive capability on deep but narrow searches. For broad axiom bases 
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the inference space rapidly gets out of hand, thus reducing speed and 
requiring large amounts of core storage. 

The QA 3. 5 package is on Caltech's System directory and is available 
to anyone with a valid account number to the PDP-10. 

Due to the above limitation of theorem-prover-based systems and also 
due to the broad general requirements for the JPL-Robot's Mars application, 
along with the consideration that the Stanford University's Shineman arm is 
being acquired for the JPL- Robot the decision was made to pursue Stanford 
University A. I. Laboratory's approach. Along this line an effort was initiated 
to study their system and bring the HE system in-house for experimentation 
and extension. 

Toward this goal a SAIL compiler and a FAIL assembler were installed 
on Caltech's PDP-10 and are currently being used to gain proficiency in their 
usage. 

The greater part of this report attempts to document the Stanford 
University A. I. Laboratory's HE system. A summary list of items accom- 
plished in Phase I of this study are: 

(1) Investigated theorem-proving techniques. 

(2) Investigated question-answering systems. 

(3) Acquired SRI's QA 3. 5 program and make it operational on 
Caltech's PDP-10. 

(4) Experimented with QA 3. 5 at Caltech. 

(5) Investigated English language (a subset of the natural language to 
first-order predicate calculus translators for the purposes of 
having more convenient front-ends to question-answering systems. 
Acquired tape of Stephen Cole's ENGROB (English Robot) program 
from SRI. 

(6) Investigated problem-solving programs such as SRI's QA4 and 
Carl Hewitt's PLANNER at MIT. Obtained a tape of a version of 
Terry Winograd's implementation called MICROPLANNER. 

(7) Investigated PDP-10 Tenex operating system, paging capabilities, 
fork structure, and communications capabilities. 

(8) Investigated Caltech's version 5 PDP-10 operating system. 

(9) Initiated dialog with Stanford University A. I. Laboratory personnel. 
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( 10 ) 

( 11 ) 

( 12 ) 

(13) 

(14) 

(15) 

( 16 ) 

(17) 

(18) 


Formulated methodology for developing a cognitive operating 
system for JPL Robot. 

Acquired documentation on Stanford's HE system based on PDP-10 
and PDP-6 computers. 

Acquired computer listings of HE monitor, global segment run 
time routines, and message procedures. 

Acquired mag tape of the complete Stanford HE system. 

Made listings of the HE system tape at JPL. 

Acquired tapes of DECUS's version of SAIL and FAIL. 

Made SAIL and FAIL operational on Caltech's PDP-10. 

Documented the salient features of Stanford's HE system for the 
purposes of importation to JPL. 

Formulated guidelines for Phase II and estimated magnitude of 
manpower requirements for the completion of this task. 


B. An Estimate of Phase II 


During Phase I, the general problem solving area was surveyed for 
applicability to the development of a cognitive operating system for the JPL- 
Robot. The emphasis was placed on bringing in-house Stanford University 
A. I. Laboratory's HE software system. Toward this end the HE system was 
studied in some detail, and the software infrastructure (SAIL compiler, 

FAIL assembler, etc. ) was established on Caltech's PDP-10. 

Along with the acquisition of an understanding of the HE system, 

Digital Equipment Corporation's latest 5 series version operating system 
was studied. This revealed that many of the features, such as TTYs, upper 
segment writability, and special CALLIs which were pioneered at Stanford, 
have now been incorporated into the Standard 10/50 DEC operating system. 
Thus the operating system of Caltech's PDP-10 makes available to the user 
the PTY mechanisms, provides the capability to remove write protection 
from upper segment under program control, and provides an extended set of 
CALLIs. These extensions of DEC's capabilities make the implementation 
of Stanford's HE system at Caltech quite feasible. 

Thus, of the primary modules of the HE system, the one that will 
require the most effort will be in the implementation of the "message 
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procedure" mechanism (which enables jobs to communicate with each other 
via the global segment). 

It is recommended that the transition first be made to the standard 
10/50 PDP-10 system. Once that is accomplished, then operation of the 
system under Tenex 10/50 compatibility mode (either in BBN's Tenex or 
under Tenex mode of DEC'S KI10) should be initiated. The next step should 
be that of rewriting the system to make use of Tenex's paging features, fork 
communications, and backtracking capabilities. 

The manpower requirements for Phase II of this task, i. e. , to have an 
operational HE-type software system on the PDP-10 in the Booth Computing 
Center at Caltech is estimated to be between 3 and 6 man-months now that a 
clear understanding of Stanford's HE system has been gained and the software 
infrastructure to do the job has been established. 
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Fig. 6. Message procedure trace 
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APPENDIX A 


HAND/EYE SYSTEM JOBS 

The eight major jobs defined in the Hand/Eye system are the following: 

EDG: Edge follower scans the TV's field of view, using a coarse 

raster, looking for edges. It then traces around the edges to 
find outline of object. 

SIM: Simple body recognizer. It gets the corner coordinates of the 

objects in the global model and applies various tests to obtain 
a prediction as to what the object may be. 

CAM : Changes the status of the TV camera, e. g. , change lens, pan, 

tilt, pan and tilt, focus, focus and pan, focus and tilt, focus, 
pan and tilt, center. 

VER: The verifier is called to determine whether or not an edge or 

line exists between TV coordinates (XI, Yl) and (X2, Y2). 

The value of the procedure is the confidence of the program in 
the existence of an edge. 

COL: This procedure finds the colors of the visible face of each 

object. 

DRV : Arm driver. The potentiometer readings generated by the arm 

solution program are obtained and the arm joints are servoed. 

GUN : Driver for the region finder which prepares blobs for COMPLEX. 

CUR: Curve fitter driver which tries to curve fit a set of blobs. 
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APPENDIX B 


CALLI SYMBOLICS 


DEC STANDARD 



CX RESET, RESETUUO 

CX DDT I N, DDT IN 
CX St TOOT, SETDOT 
CX DDTOOT , DDTOOr 
C X Of V C H R , 3 V C H P 
CX ODTGT.cF’CPJ 
CX GETCHN, DVCHK 
CX 0 0 T f ; l. , C P 0 f’ J 

cx wait, wait 

CX CORE, COR UUG 
CX EXIT, EXIT 
CX UTPCL P , OTFCLR 
CX DATE, DATE 
CX LOG IN, LOG IN 
CX APREN'P, APRENH 
CX LOGOUT, LOGOUT 
CX SWITCH, SWITCH 
CX RE ASSIGN, REASSIGN 
CX TIMER, TIMER 
CX MST IMF, MET I ME 
CX CETPPN.GETPPN 
CX TRPSET , IJUOERR 

CX trpjcn.uuuerr 

CX runtim, JCDTIM 
CX P J 0 [. , J 0 H N 0 
CX SLEEP, SLEEP 
CX SETPOV.SilTpOV 

CX PEEK, peek 

CX GETLIN, GETLN 
CX RUN, UUQERR 
CX Sf.TUWP, s-tuwp 
CX REMAP, remap 
CX GETSEG, L'UOERP 
CX GETTAP,UU3ERR 

STANFORD DEFINED 


; 0 RESET TO 
; 1 EXT-GET DOT CHAR, 

SETJDT LUC IN PROTECTED JOB OATa 
; 3 EXT {SEND PUT CHAR, 

; 4 DEVICE CHARACTISTICS 

; 5 GET DOT MODE 

;S DEVICE CHAR.CPIFF, NAME) 

; 7 release OPT MODE 

!10 WAIT TILL DEVICE INACTIVE 

; 11 CORE JUO 

iX2 EXIT 

(13 CLEAR DEC TAPE DIRECTORY 
; 14 GET DATE 
; IS LOGIN 

! 16 ENABLE APR FOR TRAPPING 
; 17 LOGOUT 

l 20 RETURN DATA SWITCHES 
UX REASSIGN DEVICE TO ANOTHER JOB 
',22 RETURN JIFFY CLOCK TIME 

r-i.i petijrn time of day in ms 

i?.A RETURN PROJECT-PROGRAMMER NUMBER 
iJM SET PI TRAP LOG, AND USER ID 
(26 DISMISS INTERRUPT TO EXEC MODE 
',11 RETURN TOTAL JOB RUNNING TIME 
; 30 RETURN JOB NUMBER 

(.31 sleep FOR n seconds, then RETURN TO USER 
1 Y2 SET PUSH DOWN OVERFLOW TRAP 
I (FOR COMPATIBILITY ONLY) 

J 33 PEEK INTO SYSTEM CORE , jJS 

(34 GET NAME OF TTY 

! 3ii RUN COMMAND 

(36 SET USER WRITE PROTECT 

(37 REDO CORE MAP 

;4i: GET SEGMENT 

(41 GETTAB ILLEGAL AT STANFQPD, 


CX 

SPCWAR, SPCWAR 

10 

cx 

CTLV.CTLV 

(1 

cx 

3c TNAM.SETNAM 

12 

cx 

SPCWGO , SPCWGO 

i 3 


READ SWITCH REGISTER JJS 

PUT TTY IN NON-D'JFLEX MODE, JJS 
SET JOB NAME FDR SYSTAT 
ANOTHER SPaCEWAR 'JUO 
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OX 3 w A P , S Y 3 R J 9 
OX L'lOTM.ElOTM 
OX LIOTM.LIQTM 
CX PNAlit , ON A ME 
OX UF3GET , UrBGET 
OX IJFBGIV.UrPGlV 
ox upbclr.pbplush 

CX JSToT S , Us T A T 
CX TT YIOS, TTYIOS 
CX cor 9 2«cor e !? 

CX atts s P» a tts°9 
CX detseg,dats fi 3 
CX setoro, setpro 
CX segnum, sannum 
CX segs i z , sans I z 
CX || nkun , I i nkup 
CX d I sra ! s , d ; sm I s 
CX I n t n b , i n t n b 
CX Intern, intor. 7i 
CX I n t a c m , Intacn 
CX intns» I n t n s 
c X lntllp»int|lp 
OX Irit I r«j, I nt I rq 
CX Intgen.lntgen 
CX uwa 1 1 » jwa 1 1 
CX debraak, debreak 
CX tnm? , se t nm£ 

CX segnain, sepne.m 
cx i wait,! wait 
CX usklD»usklp 
CX Ojf I e n , b u f | e n 
CX name I n , name I n 
CX 3 |evel,sat|v| 

CX i ent'W, i enhw 
OX run-nsk , r unmsk 
l. IoT 


; 4 RUN A JOB 

; 5 ENTER IOT user MODE 

56 LEAVE IOT USER MODE 

>7 GET A DEVICE'S PHYSICAL NAME 

510 GET A FAST BAND 
111 RELEASE A FAST BAND 

up. reuEase all fast bands 

513 GET JOB STATUS WORD OF A JOB 

514 GET A JOB'S TELETYPES STATUS WORD 
>15 Funny cor e UUO for high Segments 

516 Attach high segment 

517 Detach high segment 

•,?J ) Change protection of high segment 
>21 Ret number of high segment 

522 

523 
>24 

:25 enable Interrupts 
>26 
527 
; 30 
531 
5 32 

; 3 3 generate an Interrupt 

534 

135 

; 3 6 set name of upper, If any 
; 3 7 get name of upper, If any 

540 

541 Skip if a UWA IT r 0 a|ly h a s to wait, 

5 4 2 Return b u f f e r le n gth f or a device 

; 43 See If this Job name exists 
544 Set or get service level, 

5 45 Enable interrupts and Immediately go into 
5 46 Sets processor run mask wait state 
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APPENDIX C 


A TRACE OF HAND/EYE SYSTEM EXECUTION 


29 Mar 1972 

14109 TRAC53.DBGC2,! 

TTY-MON OJSKIN 

HEMACRC 1 1 # HE 3 

DISK-MON 

DEFINE EOGRUN 

DISK-MACR 

EDGiLOG 

DISK-MACR 

EDGiRUN DSK EOGEC 1 1 , HE J 

DISK-MACR 

EDGjGATER 

D I SK-MACR 

DRV) 

DISK-MACR 


mon-tty edgrun 

DEFINED 

DISK-MON 

DEFINE CURRUN 

DJSK-MACR 

CURlLOG 

disk-macr 

CURiRUN DSK CURVE C 1 2 » HE 3 

DJSK-MACR 

CURjGATER 

disk-macr 

DRV) 

DISK-MACR 


MON-TTY CURRUN 

DEFINED 

D I SK-MON 

DEFINE CAMRUN 

DISK-MACR 

CAMiLOG 

u i SK -M aOw 

CAMiRyN DSK CAMERAS II # HE 3 

DISK-MACR 

CAM j CATER 

DISK-MACR 

DRV) 

DISK-MACR 


MON-TTY CAMRUN 

DEFINED 

djsk-mon 

define iirun 

DISK-MACR 

ORViLOG 

DISK-MACR 

DRV i RUN DSK MORVCII»HE3 

DISK-MACR 

ORVjGATER 

DISK-MACR 


MON-TTY I I RUN 

DEFINED 

DISK-MON 

DEFINE SIMRUN 

DISK-MACR 

SJMiLOG 

DISK-MACR 

SIM, RUN DSK SIMPLEC 1 1 , HE 3 

DISK-MACR 

SIMjGATER 

DISK-MACR 

DRV) 

DISK-MACR 


MON-TTY SIMRUN 

defined 

DISK-MON 

define COLRUN 

DISK-MACR 

CODLOG 

DISK-MACR 

COL i RUN DSK C0L0RC1I,HE3 

DISK-MACR 

COLjGATER 

DISK-MACR 

DRV, 

DISK-MACR 


MON-TTY COIRUN 

DEFINED 

DISK-MON 

DEFINE VERRUN 

DISK-MACR 

VERlLOG 

DISK-MACR 

VERjRUN DSK VER I F YC 1 1 , HE D 

DISK-MACR 

VERjGATER 

DISK-MACR 

DRV) 

DISK-MACR 


MON-TTY VERRUN 

DEFINED 

DISK-MON 

define handrun 

DISK-MACR 

HAND»LOG 

DISK-MACR 

(RUN DSK HANDS 1 1 » HE] 
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DISK-MACR 


handjgater 

Oisk«macr 


ORVJ 

OIsK-MACr 



MON-TTv HANORUN 

DEFINED 

DJSK-MON 


define moverun 

DJSK-MACR 


MOVE l LOG 

DISK-MACR 


1 RUN DSK MOVE C 1 1 # HE 3 

DISK-MACR 


MOVE ) GATER 

DISK-MACR 


DRV j 

DISK-MACR 



MON-TTY MOVERUN 

DEFINED 

DISK-MON 


define setup 

DISK-MACR 


l 1 1 RUN 

DISK-MACR 


1 (TRACE 

DISK-MACR 


: l SET TYPE 

OISK-MACR 



MON-TTY SETUP DEFINED 

DISK-MON 


DEFINE ANDY 

DISK-MACR 


ORViLOG 

DISK-MACR 


1 RUN DRIVERCH, JAM] 

DISK-MACR 


J 1 SET TYPE 

OISK-MACR 


s (Trace 

DISK-MACR 


drv i cater 

DISK-MACR 



MON-TTY ANDY 

defined 

mon-tty END 

DISKIN 

tty-mon setup 


macr-mon 


1 1 RUN 

MACR-MON 


LOG 

MACR-ORV 


L 

MACR-ORV 


2/KKP 

MON-TTY DRV 

LOGGED IN AS JOB 26 

drv-tty 



MACR-MON 


RUN DSK 1 1 DRVC 1 1 , HE 3 

MACR-ORV 


RUN DSK IIORVCII.HE] 

DRV-TTY 



MACR-ORV 


GATER 

mon-tty end 

MACRO 

drv-tty ,tC 



macr-mon 


TRACE 

drv-tty 



MACR-MON 


SET TYPE 

mon-tty END 

MACRO 

DRV-TTY .SEGMENT LOGICAL NAME? 

DRV-TTY 



DRV-TTY 



ORV-TTY 



DRV-TTY 



DRV-TTY 



DRV-TTY 



drv-tty 



drv-tty 
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ORV-T TY 
DRV-TTY 
ORV-TTY 

DRV-TTY UTILITY ROUTINES INITIALIZED 
ORV-TTY « 

TTY-MON CAMRUN 

MACR-MON LOG 

MACR-CAM L 

MACR-CAM 2/KKP 

MON-TTY CAM LOGGED IN AS JOB 27 

CAM-TTY 

MACR-MON run DSK C AHER a E 1 1 , HE 3 

MACR-CAM RUN OSK CAHERAC 1 1 , HE ] 

CAM-TTY 

macr-cam gater 

MACR-DRV 

MON-TTY END MACRO 
CAM-TTY , »C 
CAM-TTY 

TTY-MON EDGRUN 

macr-mon LOG 

macr-edg L 

MACR-EDG 2/KKP 

MON-TTY EDC LOGGED IN AS JOB 28 
GAM-TTY » SEGMENT LOGICAL NAME? 

EDG-TTY 

MACR-MON run DSK EDGEC 1 1 , HE3 

MACR-EDG RUN DSK EDGEC 1 1 » HE 3 

CAM-TTY DATXFRl RETRIEVING DATACl.SHYJl 
EDG-TTY 

MACR-EDG GATER 

CAM-TTY DATXFRl RETRIEVING DATAC1,SHY]2 
MACR-DRV 

MON-TTY END MACRO 
TTY-MON CURRUN 

macr-mon LOG 

MACR-CUR L 

MACR-CUR 2/KKP 

MON-TTY CUR LOGGED IN AS JOB 29 
CAM-TTY DATXFRl RETRIEVING 0ATAC1|SHY33 
EDG-TTY .SEGMENT LOGICAL NAME? 

CUR-TTY 

MACR-MON RUN DSK CURVECIIiHE] 

MACR-CUR RUN DSK CURVECIIiHE] 

CAM-TTY DATXFRl RETRIEVING 0ATACliSHYJ4 
EDG-TTY • 

CUR-TTY 

macr-cur gater 

CAM-TTY CAM.UPOl POTS TOO NOISY <13 2 13) 

MACR-DRV 

MON-TTY END MACRO 
CUR-TTY ,tC 
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CUR-TTY 

TTY-MON SJMRUN 
MACR-HON LOG 

macr-sim L 

MACR-SIM 2/KK P 

MON-TTY SJM LOGGED IN AS JOS 30 
CAM-TTY ...TYPE Y TO TRY AGAINl 
CUR-TTY .SEGMENT LOGICAL NAME? 

SJM-TTY 

MACR-MON RUN DSK SIMPLECI I ,HE3 

MACR-SIM RUN OSK SIMPLECI I # HE 3 

SIM-TTY 

MACR-SIM GATER 

MACR-DR V 

MON-TTY END MACRO 
SIM-TTY ,»C 
SIM-TTY 

TTY-MON COLRUN 

MACR-MON LOG 

MACR-COL L 

MACR-COL 2/KK P 

MON-TTY COL LOGGED IN AS JOB 31 

SIM-TTY .SEGMENT LOGICAL NAME? 

col-tty 

MACR-MON RUN DSK COLORCIJ.HE] 

MACR-COL RUN DSK COLOR C 1 1 , HE 3 

SIM-TTY WARNING! TWO PROGRAMS WJTH ITEMS IN THEM 

COL-TTY 

MACR-COL CATER 

MACR-DRV 

MON-TTY END MACRO 
TTY-CAM 

CAM-TTY CAM-ACTIVATED 
COL-TTY .SEGMENT LOGICAL NAME? 

TTY-MON STAT 


DRV-TTY 

26 

II 

1 1 DRV 

2 » KKP 

IOWO 

28K 

010.383 

010,38 

cam-tty 

27 

CAM 

CAMERA 

2 » KKp 

I OWq 

14K 

010,683 

010,68 

EDG-TTY 

28 

edge 

EDGE 

2, KKP 

INTWQ 

35K 

010,316 

010.31 

CUR-TTY 

29 

CURVE 

CURVE 

2 1 KKP 

IOWO 

18K 

010,200 

0)0,20 

SIM-TTY 

30 

SJMP 

SIMPLE 

2, KKP 

IOWO 

33K 

010,333 

010,33 

col-tty 

31 

COL 

COLOR 

2 # KKP 

IOWO 

29K 

010,383 

010,38 

MON-TTY 
TOTAL CORE » 

191K UPPER 

SEG«18K 

MAX«65K 

12K LEFT 


TTY-MON TRACE 
TTY-MON SET TYPE 
TTY-EUG DEBUG EDGE ON 
EDG-TTY * 

TTY-ORV BLOB-GETEDGEI0) 

ORV-TTY SENDING INSJQE NIL 

49954733 MESSAGE TRACE! II EDGE INSIDE IvV 

drv-tty waiting for response inside 

EDG-TTY DAC SET AT 62 AD» 2711 
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1 AO" 


1884 


DAC SET AT 
STAT 


EOG-TTY 

28 

edge 

EDGE 


2. KKp 

EDG-TTy 

DAC SET 

AT 

31 

AD* 

1892 

EDG-TTY 

OAC SET 

AT 

46 

AD" 

1897 

EOG-TTY 

DAC SET 

AT 

54 

AO* 

2181 

EDG-TTY 

OAC SET 

AT 

50 

AD" 

1907 

EDG-TTY 

DAC SET 

AT 

52 

AD" 

2038 

EDG-TTY 

DAC SET 

AT 

51 

AD" 

1974 

EDG-TTY 

AUTO TARGET SET 

AT 

50 


EDG-TTY 

REINIT 

TCL IP" 

3 

BCLIP* 


EDG-TTY 

DAC SET 

AT 

50 

AD" 

1903 

EOG-TTY 

CLIPSET 

TCL I P» 

7 

BCLIP 


EDG-TTY 

XTENT OK 




EDG-TTY 

kkp i found matching end 



50150600 

message 

TRACEl 

EDGE 

11 

ORV-TTY 

waiting 

for response inside 


50158716 

message 

TRACEl 

EDGE 

II 

ORV-TTY 

• 





TTY-DRV 

BLOB« 






014,616 


RESPONSE "FIND" 3788 0 
RESPONSE "INSIDE" 4028 -2 


BLOB NOT RECOGNIZED OR ILLEGAL 


■ <BLOB„l) 

• 

BLOB-INNER(BLOB) 

SENDING FINE 0LOB.1 
S MESSAGE TRACEl II 

WAITING FOR RESPONSE FINE 
i MESSAGE TRACEl EDGE 


CURVE CURVE.FIT FAR 


000006 WORDS COLLECTED - GARCOL 


000000 WORDS COLLECTED 
KKplpgI N T SEE n BEF 0 rE 
DELETED 

CLIPSET TCL I P" 

CLIPSET TCL I P« 

CLIPSET TCLIP« 

KKP I LOOPING 
KKPl SCAN REVERSED 
CLIPSET TCLIP« 

KKPl ACCOM FAILED 

KKPl OBJECT SEEN 

KKP I HI T CURRENT OBJECT 

DAC SET AT 

DAC SET AT 

CLIPSET TcLjPi 

DAC SET AT 

OAC sET At 


GARCOL 


7 BCL IP" 
7 BCL IP" 
7 BCLIP" 


7 BCLIP" 


53 AD" 

50 AD" 

7 BCLIP" 
53 AD" 

56 AD" 
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EDC-TTY CLIPSET TCLJP* 

EDG-TTY KKP» OBjECT SEEn 

edg-tty kkpjhit current object 

EDG-TTY KKP I SCAN REVERSED 


4 BCLJP* 


EDG-TTY 

KKP 1 H I T CURRENT OBJECT 





EDG-TTY 

DAC SET AT 

53 

AD* 

2130 


EDG-TTY 

DAC SET AT 

50 

AD* 

1926 


EDG-TTY 

CLIPSET TCLJP* 


7 BCLIP* 


7 

EDG-TTY 

DAC SET AT 

53 

AD* 

2126 


EDG-TTY 

DAC SET AT 

56 

AD* 

2320 


EDG-ttY 

DAC s e T Af 

53 

AD* 

2130 


EDG-ttY 

DAC s Et Af 

50 

AD* 

1922 


EDG-ttY 

CLIPcEt tcljp* 


7 BCLIP* 


7 

EDG-TTY 

CLIPSET TCL I P- 


7 BCLIP* 


7 

EDG-TTY 

CLIPSET TCL I P* 


7 BCLIP* 


7 

EDG-TTY 

KKP 1 ACCOM FAILED 





EDG-TTY 

KKP 1 SCAN REVERSED 





EDG-TTY 

kkpilooping 





EDG-TTY 

DAC SET AT 

53 

AD* 

2130 


EDG-TTY 

DAC SET AT 

56 

AD* 

2327 


EDG-TTY 

KKP 1 HIT END OF PREVIOUS 

object 




EDG-TTY 

KKP 1 SCAN REVERSED 





EDG-TTY 

KKP 1 HI T CURRENT OBJECT 





EDG-TTY 

KKP 1 TRY FOR MORE 





EDG-TTY 

KKPlHJT CURRENT OBJECT 





50416033 MESSAGE TRACE! EDGE CURVE CURVE.FIT FAR 



EDG-TTY 

DAC SET AT 

53 

AD* 

2132 


EDG-TTY 

CLIPSET TCLJP* 


2 BCLIP* 


4 

EDG-TTY 

KKP 1 ACCOM FAILED 





EDG-TTY 

KKP 1 OBJECT SEEN 





EDG-TTY 

KKP 1 HI T CURRENT OBJECT 





EDG-TTY 

KKP 1 SCAN REVERSED 





EDG-TTY 

KKP » H I T CURRENT 08JECT 





EDG-TTY 

KKP ! PO I NT SEEN BEFORE 





EDG-TTY 

DELETED 





EDG-TTY 

DAC SET AT 

56 

AD* 

2327 


EDG-TTY 

DAC SET AT 

53 

AD* 

2132 



50466650 MESSAGE TRACE! 

EDG-TTY KKP I PO I NT SEEN BEFORE 
EDG-TTY DELETED 
EDG-TTY DAC SET AT 
EDG-TTY DAC SET AT 


EDGE CURVE CURVE.FIT FAR 


50492933 


MESSAGE TRACE! EDGE 


56 AD* 

53 AD* 

CURVE CURVE.FIT 


FAR 


2336 

2131 


EDG-TTY 

DATA 

MISSED 

- TV 






EDG-TTY 

HUNG 

DEVICE 

AD 






EDG-TTY 

TYPE 

C<CR> 

TO CONTINUE, 

ANYTHING 

ELSE 

<CR> 

TO 

RETRY 

TTY-EDG 

EDG-TTY 

HUNG 

DEVICE 

AD 






EDG-TTY 

TYPE 

C<CR> 

TO CONTINUE, 

ANYTHING 

ELSE 

<CR> 

TO 

RETRY 

EDG-TTY 

HUNG 

DEVICE 

AD 






EDG-TTY 

TYPE 

C<CR> 

TO CONTINUE, 

ANYTHING 

ELSE 

<CR> 

TO 

RETRY 


TTY-EDG 
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EDG-*TT Y HUNG DEVICE AD 

EDG-TTY TYPE C<CR> TO CONTINUE, ANYTHING ELSE <CR> TO RETRY 
EDG-TTY HUNG DEVICE AD 

EOG-TTY TYPE C<CR> TO CONTINUE, ANYTHING ELSE <CR> TO RETRY 
TTY-EDG C 

EDG-*TTY DAC SET AT 50 AD* 

TTY-MON S 
TTY-EDG S 
EDG-TTY 

50586750 MESSAGE TRACE! EDGE II RESPONSE "FINE" 4028 

EDG-TTY • 

ORV-TTY • 

TTY-EOG blob 
edg-tty com err blob 

EDG-TTY • 

TTY-DRV BLOB 
DRV-TTY s <> 

DRV-TTY • 

TTY-EDG REJECT -1 
EDG-TTY REJECT 4028 -1 
EOG-TTY • 

TTY-EOG BLOB^GETEDGE ( 1 ) 

EDG-TTY COM ERR BLOB-GETEDGE ( 1 > 


EDG-TTY * 

TTY-DRV SL0B*=GETEDGE«1) 

ORV-TTY SENDING FIND NIL 

50639533 MESSAGE TRACE! II EDGE FIND IvV 

DRV- TTY WAITING FOR RESPONSE FIND 

EOG-TTY COLOR WHEEL IS HUNG I RETRY OR CONTINUE <R OR C> 


TTY-EOG 

R 




EDG-TTY 

DAC SET AT 

1 

AD* 

1883 

EDG-TTY 

DAC SET AT 

48 

AO* 

1886 

EDG-ttY 

DAC §Et Af 

49 

AD* 

1897 

edg-tty 

edg-tty 

DAC $Et At 

auto target S^T 

REINIT TCLIP* 

50 

at 

AD* 

1918 

50 

EDG-TTY 

3 

BCLIP* 

EDG-TTY 

EDG-TTY 

PARITY ERROR, IN 
LOC* 7020 

YOUR 

CORE 

IMAGE! 


4 


EDG-TTY *C 
EDG-TTY 
EDG-TTY ,? 

EDG-TTY ERROR IN JOB 28 
EDG-TTY ILL MEM REF AT USER 7020 
EDG-TTY tC 
EDG-TTY 
TTY-MON S 
TTY-EOG S 
EDG-TTY ,tC 
EDG-TTY 
EDG-TTY , 

EDG-TTY DAC SET AT 
EDG-TTY DAC SET AT 


1 AD* 1851 

25 AD* 1872 


-1 


-1 
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EDG-TTY OAC SET AT 37 AD* 1883 

EDG-TTY OAC SET AT 50 AO* 1918 

EDG-TTY AUTO TARGET SET AT 50 

EDG-TTY REINIT TCLlP* 3 BCLIP* 4 

EDG-TTY ? 

EDG-TTY ERROR IN JOB 28 
EDG-TTY ILL MEM REP AT USER 7020 
EDG-TTY »c 
EDG-TTY 

TTY-MON RUN EOGEC 1 1 , HE 3 
TTY-EDG RUN EOGEC I I , HE 3 
EDG-TTY ,tC 
EDG-TTY 

EDG-TTY .SEGMENT LOGICAL NAME? 

TTY-EOG CATER 


EDG-TTY 

OAC 

SET 

AT 

1 

AD* 

1847 

EDG-TTY 

DAC 

SET 

AT 

25 

AD* 

1878 

EDG-TTY 

DAC 

SET 

AT 

37 

AD* 

1885 

EDG-TTY 

DAC 

SET 

AT 

50 

AO* 

1918 


EDG-TTY AUTO TARGET SET AT 50 

EDG-TTY REINIT TCLlP* 3 BCLIP* 4 

EDG-TTY XTENT OK 
EDG-TTY 

EDG-TTY 000000 WORDS COLLECTED - GARCOL 
EDG-TTY KKP | POUND M A TCH I NG END 

50821600 MESSAGE TRACE! EDGE II RESPONSE "FIND" 3785 0 

50822183 MESSAGE TRACE! EDGE II RESPONSE "FIND” 4020 -1 

drv-tty waiting for response find 

EDG-TTY • 

DRV-TTY • 

TTY-DRV BLOB-CURVE(BLOB) 

DRV-TTY SENDING PIT BLOB. 2 

50832150 MESSAGE TRACE! II EDGE PIT JvV 

DRV-TTY WAITING FOR RESPONSE FIT 

50834033 MESSAGE TRACE! EDGE CURVE CURVE. FIT FAR 

50841783 MESSAGE TRACE! EDGE II RESPONSE "PIT" 3785 0 

DRV-TTY • 

tty-drv REJ* 
orv-tty * 

TTY-DRV OBJ"SIMPLE(BLOB,(ALL),REJ) 

DRV-TTY SENDING S I Mp_r I T BL0B.2 

50862433 MESSAGE TRACE! II SIMP SIMP FIT ItV 0 FLdIvR 

SIM-TTY I AM NOW JN SIMPLE 

SIM-TTY NUMBER OP CORNERS IS 6 

SIM-TTY JTS'S A RECTANGULAR PARALLELEPIPED, 

SIM-TTY INSTANCE TRANSFORM FROM SIMPLE 


SIM-TTY 

-.957403 

-.288490 

, 000000 

27,2563 

SIM-TTY 

,288490 

-.957483 

, 000000 

27.6449 

SIM-TTY 

, 000000 

, 000000 

1 ,00000 

,625000 

SIM-TTY 

, 000000 

, 000000 

, 000000 

1,00000 

DRV-TTY 

• 




TTY-DRV 

D I SP.OB J ( OB J , 

1> 
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*## NO VALUE *** 


DRV-TTY s 
DRV-TTY * 

TTY-MON RESET 01 
TTY-DRV COLEI NO (OBJ ) 

ORV-TTY C0LF1ND NOT RECOGNIZED OR 
DRV-TTY OBJ) 

DRV-TTY * 

TTY-DRV COL.FIND(OBJ) 

ORv-TTy COL. FIND NOT RECOGNIZED OR 
ORV-TTY OBJ) 

DRV-TTY » 

TTY-MON UPDATE 


ILLEGAL 

illegal 


34 


JPL Technical Memorandum 33-568 

NASA - JPL - Com I,, L.A., Calif. 



